═══ 1. Introduction ═══ Please read this document in entirety. I took the time to make it explicit, clear, and very useful. It took me longer to write it than it will ever take you to read it. Therefore, you owe it to both of us to read it. OK? SysXDump is an OS/2 2.X command line application that allows you to dump MIDI System Exclusive information (ie, Patch settings, waveform data, etc) from your external MIDI gear to the computer, and store that information on your computer's media (ie, hard drive, floppies). Subsequently, SysXDump data files can be sent back to the MIDI gear, again using SysXDump, to quickly restore those settings on the MIDI gear. So, this utility allows you to backup and restore the settings of MIDI gear, utilizing the computer's storage medium. Typically, floppy disk and hard drive storage is much cheaper than those RAM cards or some sort of dedicated MIDI "recorder" to capture SYSEX dumps. SysXDump also allows handshaking for most Roland gear, or any MIDI sampler that follows the MIDI Sample Dump Standard (ie, Prophet 2000/3000, Emu Emulator/Emax, Peavey SP/DPM/SX, AKAI S1000 and derivatives, etc). This not only allows you to verify the dump for any errors, but often also improves the speed of transfer. Some of the words in this manual are highlighted in bold text, such as Handshake. These are words that refer to SysXDump menu choices which you can choose. Other words are in colored text such as Channel Pressure. These refer to MIDI messages (ie, data). Underlined words, such as Pitch Wheel, refer to hardware, such as if I was referring to the Pitch Wheel on your MIDI unit. Words that are in colored text such as Read This are meant to be emphasized. Words in italics refer to aspects of OS/2. This is version 1.0, copyright 1994 by Jeff Glatt. ═══ 2. Driver Requirements and Setup ═══ Of course, your computer needs some sort of MIDI interface card (ie, with MIDI IN and OUT jacks) to connect the computer to the MIDI unit. Many Sound Cards offer the option of attaching a "box" with MIDI connectors to the card's joystick port. This is the same thing as having a separate card that just does MIDI input and output. SysXDump requires that your MIDI interface or Sound Card has an OS/2 driver. Information sent to this driver via DosWrite() must be interpreted as outgoing MIDI data. (It would have to be a rather strange driver if it didn't interpret data in this way, but if you're using a sound card with WAVE playback in addition to a MIDI interface, it's conceivable that the Sound Card might interpret DosWrite() data to be WAVE data). Furthermore, information returned by this driver via DosRead() must be incoming MIDI data. Note: SysXDump does not use MMPM. Such a driver will not work with SysXDump unless it meets the above requirements. Certain drivers are not very well-written, and they will crash the entire system if a program sends them particular streams or values of bytes via DosWrite(). An OS/2 driver is never supposed to do this. After all, this is a "protected" OS, and DosWrite() is supposed to be a completely generic way of sending any stream of bytes to a driver. But due to its ring 0 nature, a physical device driver (ie, PDD) has the power to completely trash your entire system. For example, the Sound Blaster MMPM driver does dangerous things with data sent via DosWrite(). Use that driver with this software only at your own risk. For your own sake, never redirect the stdout of any program to this driver, or you may be reinstalling OS/2 on your HD. You'll know if a driver crashes your system, as versus an application, because an application will simply pop up a recoverable exception requester that lets you safely remove it from memory and continue, but a crashed driver may very well bang on your hardware, trash your HD, cause a Register Dump from which you'll have to reboot the computer, or do a number of very dangerous things. Badly written drivers are deadly because, unlike with a 32-bit (protected mode) program running at ring 3, the OS can't protect itself, other programs, and your computer's hardware from an evil PDD. You must also know your driver's internal name (which might be different than the filename of the driver). Often, this is the driver filename minus the .SYS extension. For example, I use a Roland RAP-10 audio card which has an MPU-401 compatible MIDI interface built into it. There is a shareware OS/2 driver available for the MPU-401 by the following manufacturer: Delta Music Systems 2615 Ginghamsburg-Frederick Rd. Tipp City, OH 45371 This driver's internal name is MPU401. It properly interprets DosWrite() data as MIDI data, and ships it out of any MPU-401 compatible interface. So, you can use this driver with SysXDump, and any card that has an MPU-401 compatible interface (in hardware, not just a software driver simulation). Such cards include the MPU-401, MidiQuest interfaces, SCC-1, the RAP-10, and numerous other 100% compatible MPU-401 clones. By default, SysXDump will use that driver, and so you don't have to supply it with that name. If you want SysXDump to use a different driver, then you must supply the name of the driver to SysXDump. If you run SysXDump from an OS/2 Command Prompt, then simply type the name of your driver as an argument immediately preceeded by "/D". For example, a driver with the internal name RAP10 would be specified as /DRAP10. If you run SysXDump from a Desktop icon, open up the Settings menu for that program. In the Parameters field, type the name of your driver, preceeded by the /D. Now whenever you run SysXDump from the Desktop, it will use that driver. Note: Remember to omit the .SYS extension from the driver name. If SysXDump can't open the specified driver, it will display an error message and its template, and then terminate. If not using the Delta Music Systems driver, then specify the /N switch when invoking the program. This will cause SysXDump to skip some MPU-401 initialization code for that driver. There are other startup parameters that you can pass to SysXDump, either by adding them to the command line, or entering them in the Parameters field of the Desktop icon. These will be covered later. ═══ 3. Menu ═══ After SysXDump starts up, it presents a menu choice in an OS/2 Command Prompt Window. The menu looks like this: Enter a command: S (path\)filename to Send a data dump to the MIDI unit R (path\)filename to Receive a data dump from the MIDI unit F (path\)filespec to list Files in a directory H toggle Handshaking ON/OFF Esc Exit program You can make one of the preceeding selections. For example, if you wish to receive a data dump from the MIDI unit, press the r key on your computer. Note: It doesn't matter if you use lower or upper case (ie, r or R). Depending upon which command you select, you may be prompted to type in more input. Here is a description of each menu choice: ═══ 3.1. Handshake ON/OFF ═══ Press h to toggle handshaking ON or OFF. If it was ON, pressing h turns it off, and displays the message "Handshaking is OFF.". If it was OFF, pressing h turns it on. Then, SysXDump asks you to choose which type of handshaking, Roland or MIDI Sample Dump Standard (SDS). Press 1 for Roland, or 2 for SDS. Most Roland units support the Roland type of handshaking, regardless of what kind of unit it is. But, each Roland model has its own Model ID. Check the unit's owners manual to determine the Model ID. It's usually in the MIDI Implemention section under System Exclusive. It will be a 2 digit (hexadecimal) number. After you select Roland handshaking, SysXDump will present you with a list of Roland units whose Model ID SysXDump knows. If you find your unit in the list, select the number preceding it. If your unit is not in the list, select the Other choice. Then, you will be asked to enter that 2 digit Model ID. SDS handshaking is for samplers. SDS is a protocol for transmitting waveform data. A number of samplers support SDS. Consult your owners manual to see if your unit does. Note: If you intend to use Handshaking on transfers, turn it ON before you perform any send or receive of data. Make sure that you also set up your MIDI unit to perform handshaking on its dumps. Some units give you a choice of enabling/disabling handshaking. You can specify handshaking ON when you start SysXDump by using the /H1xx and /H2 switches on the command line. /H1xx is for Roland handshaking, where xx is the Model ID. /H2 is for SDS handshaking. For example, to start SysXDump using the BLORT driver and handshaking for a Roland D-70 (Model ID is 39): SysXDump /DBLORT /H139 If running SysXDump from a Desktop icon, you can open up the Settings and type the /H1xx or /H2 switch in the Parameters field. For example, the above example would be: /DBLORT /H139 In this way, everytime that you run SysXDump, handshaking will already be setup and enabled for a D-70. ═══ 3.2. Receive a file ═══ Press r to choose to receive a file from the MIDI unit (ie, the MIDI unit will be sending its data to the computer, to be stored in a data file on your computer's HD or floppy drive). SysXDump next prompts you to type the desired filename, followed by RETURN. You can prepend a path if you don't want the filename to be saved in the current directory. For example, to save the data in a file called Blort in the directory MyDir on your C: drive: C:\MyDir\Blort Note: SysXDump will check for the existance of the filename that you choose. If that file already exists, you will asked if you wish to overwrite (ie, erase) that file. Press Y for Yes, or N for no. If you answer No, then the operation is aborted. If using SDS handshaking, SysXDump asks you which wave number on the MIDI unit you would like to receive. Type the number and press RETURN. SysXDump will then automatically initiate the receive so that you don't have to operate the MIDI unit. If using Roland handshaking or no handshaking, you'll have to start the dump on your MIDI unit. Check the owners manual for how to do this. If SysXDump starts getting some data from your MIDI unit, you'll see the message: Receiving a SysEx dump now... Esc will abort. Pressing any other key finishes the dump. If you don't see this message, then something is wrong. SysXDump isn't receiving any data from your MIDI unit. Review all of the possible causes in No Sysex packets received!. If you see this message, then allow the dump to proceed all of the way to the end. You'll need to watch your MIDI unit for some sort of signal when the dump is completed. When the dump is done, press any key (except for Esc) to finish the receive operation. SysDump will then tell you how many bytes it received. At this point, it's a good idea to send the received data back to the MIDI unit in order to verify that it contains no errors. If you've got errors, your MIDI unit should display an appropriate message. Although SysXDump implements handshaking, it doesn't implement error-checking the CheckSum on packets. So, it's conceivable that a corrupted packet could be received and stored. But, if this were the case, when you sent the data file back to the MIDI unit, the MIDI unit would detect the error. A good policy is to do 2 receives to separate files, then follow them up with a send in order to test the integrity of the files. Once you've determined that a received file checks out OK, make a backup of it. At any time, you can press the Esc key to abort the dump. Whatever data was received up to that point is erased. Note: If you intend to use Handshaking on transfers, turn it ON before you receive any data. Make sure that you also set up your MIDI unit to perform handshaking on its dumps. Some units give you a choice of enabling/disabling handshaking. Note: Always set your MIDI unit's MIDI channel to 1 before any receive. For Roland units, set the Device ID to 1. In this way, you'll always avoid any MIDI channel or Device ID mismatches when later sending the file back to the MIDI unit. ═══ 3.3. Send a file ═══ Press s to choose to send a data file to the MIDI unit. SysXDump next prompts you to type the desired filename, followed by RETURN. You can prepend a path if the file isn't in the current directory. For example, to send the data file called Blort in the directory MyDir on your C: drive: C:\MyDir\Blort SysXDump then displays a message telling you to press any key (except Esc) to start the send. This gives you an opportunity to place your MIDI unit into a receive state, if needed. If this doesn't need to be done, then simply press any key to start the send. SysXDump will perform the send in entirety. There's no need to press any key when the send is complete. If all went well, SysXDump will display the message "Send complete.". At any time, you can press the Esc key to abort the send. Note: If you intend to use Handshaking on transfers, turn it ON before you send any file. Make sure that you also set up your MIDI unit to perform handshaking on its dumps. Some units give you a choice of enabling/disabling handshaking. Note: Always set your MIDI unit's MIDI channel to 1 before any send. For Roland units, set the Device ID to 1. In this way, you'll always avoid any MIDI channel or Device ID mismatches with the MIDI channel that the data file was initially received upon. ═══ 3.4. File Directory ═══ Press f to get a listing of the contents of some directory on your computer's HD or floppy. SysXDump will ask you to enter the directory that you wish to examine. Use a full path if not the current directory. Then, SysXDump will list the files that match that file specification. Note: You may use wild cards. For example, to list all files in the directory BLORT on the C: drive which have the extension .hnd, type: C:\blort\*.hnd ═══ 4. Error Messages ═══ Here are the possible error messages that you may see. Following each message is a description of likely causes for that error and possible remedies, and what happens as a result of that error (ie, does the program terminate, or stop transmission, or what?). When SysXDump finally terminates, as a result of a fatal error or the user exiting, if the last operation performed by the software resulted in an error, SysXDump returns a non-zero value to the OS. A 0 returned value indicates that the last operation before termination was a success. Note that this is returned in RC when calling SysXDump from a REXX script (which could be done if you wanted to implement some sort of REXX patch editor for your MIDI unit using SysXDump to perform any transfers). ═══ 4.1. XXX MIDI driver didn't open! ═══ Synopsis XXX will be the driver name that you supplied to SysXDump (the default of MPU401 is used if you didn't supply a name). This error means that the requested driver did not open, and therefore SysXDump can't do any MIDI input and output. Cause Some other program already has this driver open and has denied any other program access to it (ie, no SHARED access). Cure Terminate all other programs using this driver, and try SysXDump again. Incidentally, SysXDump allows shared access, but you should avoid simultaneously running programs that get MIDI input. Shared MIDI output is fine, but only while SysXDump is not engaged in sending a file to the MIDI unit. Cause The driver isn't installed properly with an entry in your config.sys file. Cure Check that entry in your config.sys file. Cause The name you supplied is not the true, internal name of the driver. Every driver has an ascii string embedded inside of it, which is its real name as far as OS/2 is concerned. This might not be the same as the driver's filename. Usually, it is the filename minus the .SYS extension. Cure Contact the author of the driver and verify the driver's name for a DosOpen(). Error occurs Only during program startup. Result SysXDump terminates returning RC=100. ═══ 4.2. DosDevIOCtl 0xFF error: return code = XXXXXXXX ═══ Synopsis XXXXXXXX is the error number (in hex) returned by the driver after SysXDump sent a 0xFF to its IoCtl interface. The Delta Music Systems driver uses this scheme to reset an MPU-401. That's what SysXDump needs to do when using an MPU-401. So, I do it this way. (The RAP-10 also needs to receive a 0xFF reset before SysXDump can do MIDI input on it. I've chosen to follow the Delta Music Systems protocol in the RAP-10 driver that I've written). Cause If you're not using an MPU-401 or compatible MIDI interface, then it probably doesn't need to be reset like this, its driver will probably not recognize what SysXDump is telling it to do, and you'll see the error message. Cure Specify the /N option when running SysXDump. This tells SysXDump that you don't want it to try to reset the MIDI interface using the Delta Music Systems' driver procedure. For example, if you had a driver named BLORT, and you didn't want it reset, here's what you might type as arguments when running the program (or type into the Parameters field of the Desktop icon) /DBLORT /N Error occurs Only during program startup. Result SysXDump doesn't regard this as a real error. It's essentially ignored except for displaying the message. ═══ 4.3. DosDevIOCtl 0x3F error: return code = XXXXXXXX ═══ Synopsis XXXXXXXX is the error number (in hex) returned by the driver after SysXDump sent a 0x3F to its IoCtl interface. The Delta Music Systems driver uses this scheme to place an MPU-401 into UART mode (instead of "intelligent" mode). That's what SysXDump needs to do when using an MPU-401. See the preceeding error message. Cause If you're not using an MPU-401 or compatible MIDI interface, then it probably doesn't need to be placed into a UART mode, its driver will probably not recognize what SysXDump is telling it to do, and you'll see the error message. Cure Specify the /N option when running SysXDump. This tells SysXDump that you don't want it to try to place the MIDI interface into UART mode using the Delta Music Systems' driver procedure. Error occurs Only during program startup. Result SysXDump doesn't regard this as a real error. It's essentially ignored except for displaying the message. ═══ 4.4. Can't create semaphore! ═══ Synopsis SysXDump uses multiple threads for inputting and outputting MIDI data. This allows you to abort any MIDI transfer in progress, or end the program at any time, by pressing the ESC key on your computer. SysXDump needs OS/2 to give it a semaphore for such use. Cause For some reason, OS/2 didn't give SysXDump its requested semaphore. Cure Shut down other apps, or OS/2 itself, and try SysXDump again. Error occurs Only during program startup. Result SysXDump terminates returning RC=100. ═══ 4.5. Can't start MIDI Receive thread! ═══ Synopsis SysXDump uses multiple threads for inputting and outputting MIDI data. This allows you to abort any MIDI transfer in progress, or end the program at any time, by pressing the ESC key on your computer. SysXDump needs OS/2 to startup the MIDI Receive thread. Cause For some reason, OS/2 didn't startup SysXDump's MIDI Receive thread. Cure Shut down other apps, or OS/2 itself, and try SysXDump again. Error occurs Only during program startup. Result SysXDump terminates returning RC=100. ═══ 4.6. Can't start MIDI Send thread! ═══ Synopsis SysXDump uses multiple threads for inputting and outputting MIDI data. This allows you to abort any MIDI transfer in progress, or end the program at any time, by pressing the ESC key on your computer. SysXDump needs OS/2 to startup the MIDI Send thread. Cause For some reason, OS/2 didn't startup SysXDump's MIDI Send thread. Cure Shut down other apps, or OS/2 itself, and try SysXDump again. Error occurs Only during program startup. Result SysXDump terminates returning RC=100. ═══ 4.7. Can't open file! ═══ Synopsis A file, that you asked SysXDump to open so that you can receive and store data from the MIDI unit, didn't open. Cause The filename that you specified is incorrect. Cure Check the filename that you entered. Did you specify some directory that doesn't exist? SysXDump only creates files; not new directories. Cause Some other program has this filename currently in use, and is preventing SHARED access. Cure Make that other program close this filename. Cause You chose to save data upon some media that is write-protected. Cure Remove the write-protection. Error occurs You're selecting a filename for the MIDI data about to be received from the MIDI unit. Result The error level is set to 5, and the receive operation is cancelled. ═══ 4.8. Unexpected MIDI Status. Skipping SysEx packet! ═══ Synopsis During receipt of a SYSEX message from the MIDI device, an illegal MIDI status was received, according to the MIDI spec. SysXDump will throw away the SYSEX packet. This may or may not be critical to your dump. After all, the SYSEX message might actually be a message that isn't part of the information that you requested the MIDI unit to send. The only way to check for certain that your received file is intact is to subsequently send it back to your MIDI unit, and see if the MIDI unit chokes on the send or doesn't receive all of the data you desired. Note: SysXDump properly allows (and ignores) MIDI Realtime messages sent at any time. Thus you can use the software to capture dumps even from units that implement Active Sense (ie, lots of Roland gear, which gives headaches to dump utilities that don't account for MIDI Realtime messages). Cause See above. Cure Nothing you can do really. If you see this message during a receive, then immediately try the receive all over again. Hopefully, the second time will result in no such error. It's always good to do a couple of receives of your data and save to different files. Then, you'll have backups. Error occurs Anytime during a SYSEX dump, send or receive. Result Since this may not be a real error (but you should always try the dump again if you see this message, just to be safe), SysXDump ignores it. ═══ 4.9. Error writing to the file after X bytes! ═══ Synopsis While receiving MIDI data from the unit, there was a problem with being able to write a piece of data to the file that you specified. The X will be the number of bytes successfully received up to the point when the error occurred. Cause The media is full. (The number of successfully received bytes should have filled up your media). Cure Make sure that there is enough room on the media to contain the number of bytes that you intend to receive from the MIDI unit. SysXDump can't predict required space before receiving the data, so use your own judgment. Error occurs Anytime during a SYSEX receive from the MIDI unit. Result The error level is set to 5, the receive operation is cancelled, and the incompletely received file is erased. ═══ 4.10. No Sysex packets received! ═══ Synopsis At the end of a receive operation (ie, when you finally press some computer key, other than ESC, to tell SysXDump not to look for any more incoming MIDI data), SysXDump checks to see if it actually received any data from the MIDI unit. If not, it posts this message. Cause There's something wrong with your MIDI cable connections. Cure Make sure that IN's go to OUT's on the MIDI interface and unit. For handshaking, you need a 2 way connection. Make sure that you don't have a bad cable. Cause Your MIDI unit aborted before sending any data. Cure If your MIDI unit provides its own "progress display", watch it during the transfer to verify that your unit is not aborting before sending any data. Maybe you're trying to do a handshaking transfer without enabling SysXDump's handshaking (in which case, SysXDump is never telling the unit to proceed with the dump). Don't use Roland or SDS handshaking for a unit that doesn't support one of these protocols. Instead, have your unit do a non-handshaking dump, and disable SysXDump's handshaking. Cause Your handshake settings are incorrect. Cure If doing an SDS handshake receive, make sure that your MIDI unit is set to MIDI channel 1. Roland device ID should also be set to unit 1. Cause Your driver and/or interface card isn't feeding MIDI input to SysXDump. Cure Contact the driver author to verify that the driver meets the requirements outlined in the section Driver Requirements and Setup. Try the interface card with its included software to verify that it is receiving MIDI data from your MIDI unit. Error occurs At the end of a receive operation. Result The error level is set to 5, and the empty file is erased. ═══ 4.11. Can't find this file! ═══ Synopsis A file, that you asked SysXDump to open and send to the MIDI unit, didn't open. Cause The filename that you specified is incorrect. Cure Check the filename that you entered. Did you specify some directory and file that exists? Note: SysXDump does not use wildcards. Cause Some other program has this filename currently in use, and is preventing SHARED access. Cure Make that other program close this filename. Error occurs You're selecting a filename for a data file to be sent to the MIDI unit. Result The error level is set to 5, and the send operation is cancelled. ═══ 4.12. Driver didn't output MIDI byte! ═══ Synopsis While sending a data file to your MIDI unit, if you see this message, then the driver didn't properly output a piece of data. Cause Your driver and/or interface card isn't accepting data from SysXDump. Cure Terminate any other program that is currently using the driver. Note: If the MIDI unit doesn't seem to be responding to the send, and you've examined your cable connections, unit's MIDI channel setting (ie, set to 1), and all other error conditions associated with handshaking, then contact the driver author to verify that the driver meets the requirements outlined in the section Driver Requirements and Setup, especially if you don't see this error message. (ie, If everything else is OK, then this means that the driver is accepting SysXDump's data, but not pushing it out of the MIDI interface). Error occurs Anytime while sending a SYSEX dump to the MIDI unit. Result The error level is set to 5, and the send operation is cancelled. ═══ 4.13. Timeout while awaiting ACK! ═══ Synopsis After sending a packet, SysXDump was waiting for an ACK response (ie, handshake) from your MIDI unit. (In other words, you've enabled SysXDump's handshaking). This response never came within a reasonable amount of time, so SysXDump assumed that your MIDI unit wasn't properly handling the send. Cause There's something wrong with your MIDI cable connections. Cure Make sure that IN's go to OUT's on the MIDI interface and unit. For handshaking, you need a 2 way connection. Cause You've enabled SysXDump's handshaking, but are sending a data file that was initially received via non-handshaking. Or vice versa. Cure If you receive data from a MIDI unit without handshaking, make sure that you turn off handshaking before sending the data back to the MIDI unit. If you receive data from a MIDI unit with handshaking, make sure that you turn handshaking on before sending the data back to the MIDI unit. Many MIDI units have different formats for data dumps depending upon whether you enable or disable handshaking on the unit. Cause Your MIDI unit isn't set to MIDI channel 1 (or if a Roland unit, it's device ID is not 1). Cure Set it so. You should always set the MIDI unit to channel 1 before receiving data to be stored on the computer. Later, when you wish to send the data back to the unit, if you set the unit to 1, this will eliminate any problems with mismatched MIDI channels (or Device ID) in messages. Cause Your Roland unit's Model ID doesn't match the ID of the unit that initially created the data. Or, you've specified the wrong Model ID for SysXDump handshaking. Cure Make sure that the unit that created the data also accepts that data being sent back to it. If so, then you've properly specified the Model ID. Cause Your MIDI unit doesn't support the handshake protocol that you're using. Cure Don't use Roland or SDS handshaking for a unit that doesn't support one of these protocols. Instead, disable SysXDump's handshaking, receive data from your unit without handshaking, and send it back likewise. Cause There's a conflict with some other unit daisy-chained to your computer's MIDI interface. Cure Disconnect all other MIDI units. Cause The file that you chose to send wasn't created by SysXDump (or some other "MIDIEX" derivative software). In other words, it's not a binary, raw SYSEX dump. Cure None. Cause Your driver and/or interface card isn't pushing SysXDump's data out of the MIDI interface. Cure Contact the driver author to verify that the driver meets the requirements outlined in the section Driver Requirements and Setup. Make sure that your interface isn't filtering SYSEX messages from its output. Error occurs Anytime while sending a SYSEX dump (with handshaking) to the MIDI unit. Result The error level is set to 5, and the send operation is cancelled. ═══ 4.14. MIDI unit aborted the send! ═══ Synopsis Your MIDI unit sent a SYSEX message that told SysXDump to abort the send. (ie, You've enabled SysXDump's handshaking). Cause You've enabled SysXDump's handshaking, but are sending a data file that was initially received via non-handshaking. Cure Make sure that you use handshaking only with data files that were initially received from a MIDI unit with handshaking. Many MIDI units have different formats for data dumps depending upon whether you enable or disable handshaking on the unit. If you try to send a non-handshaking dump when the MIDI unit expects otherwise, it may cancel the dump. Cause Your MIDI unit didn't receive the data being sent by SysXDump. Cure Make sure the unit's MIDI Channel (or Device ID if a Roland unit) is set to 1. You should always set the MIDI unit to channel 1 before receiving data to be stored on the computer. Later, when you wish to send the data back to the unit, if you set the unit to 1, this will eliminate any problems with mismatched MIDI channels (or Device ID) in messages. Usually, your MIDI unit will eventually display a "Time out" error if there is no communication happening between the computer and unit. If the channel is correct, there could be a problem with cable connection. Or, your Roland unit's Model ID doesn't match the ID of the unit that initially created the data, or you've specified the wrong Model ID for SysXDump handshaking. Make sure that the unit that created the data also accepts that data being sent back to it. If so, then you've properly specified the Model ID. Cause Your MIDI unit encountered its own internal error while accepting data. Cure Examine the error message that your unit (hopefully) displays, and consult its owners manual for solutions. Cause The data file that you're sending has a checksum error (ie, was somehow corrupted). Usually, the MIDI unit will display a message about such. Cure Send a backup file. Cause There's a conflict with some other unit daisy-chained to your computer's MIDI interface. Cure Disconnect all other MIDI units. Cause The file that you chose to send wasn't created by SysXDump (or some other "MIDIEX" derivative software). In other words, it's not a binary, raw SYSEX dump. Cure None. Error occurs Anytime while sending a SYSEX dump (with handshaking) to the MIDI unit. Result The error level is set to 5, and the send operation is cancelled. ═══ 4.15. No Sysex packets sent! ═══ Synopsis At the end of a send operation (ie, when SysXDump has successfully transmitted any and all data in the file), SysXDump checks to see if it actually sent any data to the MIDI unit. If not, it posts this message. Cause Your data file contains no data. You can check this by using OS/2's dir command to verify that the size of the file is 0 bytes. Perhaps some other software overwrote this file. Cure Send a backup file. Error occurs At the end of a send operation. Result The error level is set to 5.